command: initial batch queue cli implementation by mismithhisler · Pull Request #27909 · hashicorp/nomad

mismithhisler · 2026-05-06T19:15:24Z

Description

These changes implement a very basic command to view the contents of a batch job queue. Some of the details here are expected to change as the implementation progresses, but being able to visualize the queue will help other parts of development/testing.

Testing & Reproduction steps

Links

Contributor Checklist

Changelog Entry If this PR changes user-facing behavior, please generate and add a
changelog entry using the make cl command.
Testing Please add tests to cover any new functionality or to demonstrate bug fixes and
ensure regressions will be caught.
Documentation If the change impacts user-facing functionality such as the CLI, API, UI,
and job configuration, please update the Nomad product documentation, which is stored in the
web-unified-docs repo. Refer to the web-unified-docs contributor guide for docs guidelines.
Please also consider whether the change requires notes within the upgrade
guide. If you would like help with the docs, tag the nomad-docs team in this PR.

Reviewer Checklist

Backport Labels Please add the correct backport labels as described by the internal
backporting document.
Commit Type Ensure the correct merge method is selected which should be "squash and merge"
in the majority of situations. The main exceptions are long-lived feature branches or merges where
history should be preserved.
Enterprise PRs If this is an enterprise only PR, please add any required changelog entry
within the public repository.

If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

mismithhisler · 2026-05-06T19:23:13Z

@@ -0,0 +1,21 @@
+package api
+
+type Workload struct {


This struct might be a little TBD when we start connecting the various PR's

mismithhisler · 2026-05-06T19:28:11Z

+
+Eval Options:
+
+  -limit


This is really going to be the "TopK" workloads, so maybe mentioning this would be helpful.

tgross · 2026-05-06T19:34:47Z

+}
+
+// BatchQueueStatus is used to query the current batch job queue.
+func (j *Jobs) BatchQueueStatus(q *QueryOptions) (*BatchQueueStatusResponse, *QueryMeta, error) {


Before we land this in a release, I'd recommend having a BatchQueueStatusOptions parameter here as well. We virtually always need one and adding one later breaks backcompat with the api package and we end up with all those silly FooOptions methods.

You've already done this on the response side: the QueryMeta isn't ever going to be populated because there's no state store involved here, but you've given us the ability to add information from the state store if we want in the future.

That's probably a better spot to put things like "limit" as opposed to relying on a user putting it into the query options params.

Actually, doesn't QueryOptions have a PerPage field for pagination?

Yes it does!

tgross · 2026-05-06T19:38:15Z

+	// compute column widths
+	col0, col1, col2 := len(headers[0]), len(headers[1]), len(headers[2])
+	for _, r := range resp.Workloads {
+		if len(r.JobID) > col0 {
+			col0 = len(r.JobID)
+		}
+		if len(r.Tenant) > col1 {
+			col1 = len(r.Tenant)
+		}
+		// convert int to string for width calculation
+		l := len(fmt.Sprintf("%d", r.Priority))
+		if l > col2 {
+			col2 = l
+		}
+	}


We use columnize in most of the rest of the CLI. Why not use it here too?

Because for whatever reason I didn't think to look at how we displayed multi row output elsewhere 🤦 (well I did look at a some commands but not the right ones.)

Hmm after playing around with columnize, I think it's good for printing out small tables but if users have larger tables, it seems tough to read and less configurable. The default format ends up looking like:

JobID Tenant Priority 123100 testTenant100 100 1230 testTenant0 0 1231 testTenant1 1 1232 testTenant2 2 1233 testTenant3 3 1234 testTenant4 4 1235 testTenant5 5 1236 testTenant6 6 1237 testTenant7 7 1238 testTenant8 8 1239 testTenant9 9 12310 testTenant10 10 ...

With some Glue:

| JobID | Tenant | Priority| | 123100| testTenant100| 100 | | 1230 | testTenant0 | 0 | | 1231 | testTenant1 | 1 | | 1232 | testTenant2 | 2 | | 1233 | testTenant3 | 3 | | 1234 | testTenant4 | 4 | | 1235 | testTenant5 | 5 | | 1236 | testTenant6 | 6 | | 1237 | testTenant7 | 7 | | 1238 | testTenant8 | 8 | | 1239 | testTenant9 | 9 | | 12310 | testTenant10 | 10 | ...

vs current:

JobID | Tenant | Priority -------+---------------+-------- 123100 | testTenant100 | 100 1230 | testTenant0 | 0 1231 | testTenant1 | 1 1232 | testTenant2 | 2 1233 | testTenant3 | 3 1234 | testTenant4 | 4 1235 | testTenant5 | 5 1236 | testTenant6 | 6 1237 | testTenant7 | 7 1238 | testTenant8 | 8 1239 | testTenant9 | 9 12310 | testTenant10 | 10 ...

Admittedly I think the last one is the easiest to read when theres >10 rows. Using string formatting and strings.Builder is also quite a bit faster (although both are so fast it won't be noticeable). But I'm also hesitant to start doing something completely different than the rest of the codebase. What are your thoughts?

Yeah I'd recommend against being very different. By default we're probably going to want to paginate the list down, as we do for other list endpoints. I think this one suffers from being such a narrow column relative to the length. Maybe we can pad it out a bit for readability by changing the configuration? https://github.com/ryanuber/columnize#configuration

New updates using columnize look like this (not sorted yet):

JobID | Tenant | Priority ----- | ------ | -------- 1230 | testTenant0 | 0 1231 | testTenant1 | 1 1232 | testTenant2 | 2 1233 | testTenant3 | 3 1234 | testTenant4 | 4 1235 | testTenant5 | 5 1236 | testTenant6 | 6 1237 | testTenant7 | 7 1238 | testTenant8 | 8 1239 | testTenant9 | 9 12310 | testTenant10 | 10

CLI tables with borders are a bit awkward with awk, so I prefer it bare unless there's a --json flag or similar to be easily machine-parsable.

I think adding a --json flag is a good idea. I'm not really a fan of making the output favorable to awk at the cost of less readable, because I think json output is for parsing, or the nomad HTTP API.

Without borders this becomes weird to look at with >10 rows.

command: initial batch queue cli implementation

e07c9a9

mismithhisler self-assigned this May 6, 2026

mismithhisler commented May 6, 2026

View reviewed changes

mismithhisler requested a review from tgross May 6, 2026 19:23

mismithhisler marked this pull request as ready for review May 6, 2026 19:24

mismithhisler requested review from a team as code owners May 6, 2026 19:24

mismithhisler requested review from gulducat and schmichael May 6, 2026 19:26

mismithhisler commented May 6, 2026

View reviewed changes

add copy header

1a8fad4

vercel Bot deployed to Preview May 6, 2026 19:33 View deployment

tgross reviewed May 6, 2026

View reviewed changes

modern max calculation

5165612

vercel Bot deployed to Preview May 6, 2026 20:44 View deployment

remove leftover copy paste

27287e9

vercel Bot deployed to Preview May 6, 2026 20:49 View deployment

switch to using columnize and add status options

1f22de1

vercel Bot deployed to Preview May 6, 2026 21:35 View deployment

Conversation

mismithhisler commented May 6, 2026

Description

Testing & Reproduction steps

Links

Contributor Checklist

Reviewer Checklist

Changes to Security Controls

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mismithhisler May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mismithhisler May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gulducat May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mismithhisler May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mismithhisler May 6, 2026 •

edited

Loading

mismithhisler May 6, 2026 •

edited

Loading

gulducat May 6, 2026 •

edited

Loading

mismithhisler May 6, 2026 •

edited

Loading